Easy2Siksha Sample Paper
GNDU Most Repeated (Important) Quesons
BCA 5th Semester
SOFTWARE ENGINEERING
Most Repeated Quesons Analysis (2021-2024)
SECTION-A (Soware Process Models & Metrics)
Queson Topic
Repeats
Years Appeared
Priority
Iterave/Waterfall Model
explanaon
4 Times
2021 (Q1b), 2022 (Q1b),
2023 (Q1), 2024 (Implied)
100%
CERTAIN
Metric vs Measurement + Funcon
Point calculaon
4 Times
2021 (Q2), 2022 (Q2), 2023
(Q2), 2024 (Q2)
100%
CERTAIN
2025 GUARANTEED QUESTIONS (100% Appearance)
TOP 8 QUESTIONS - MUST PREPARE:
1. Iterave Waterfall Model vs Classical Waterfall (4/4 years)
2. Metric vs Measurement + Funcon Point Calculaon with
numerical (4/4 years)
Easy2Siksha Sample Paper
EXAM STRATEGY FOR 2025
Secon-wise Guaranteed Selecon:
Secon A:
• Q1: Iterave Waterfall Model (100% sure)
GNDU Most Repeated (Important) Answer
BCA 5
th
Semester
SOFTWARE ENGINEERING
Solved Answer Paper
SECTION-A (Soware Process Models & Metrics)
Q1. Explain the Iterave Model and the Waterfall Model. Compare their features with
examples.
Ans: The Story of Two Friends: Waterfall and Iterative
Imagine you are the leader of a team who has been asked to build a dream house. Now,
there are two main ways you can approach this task. One friend of yours, let’s call him
Mr. Waterfall, is very disciplined, organized, and believes that every step should be
completed before moving to the next. Another friend, Mr. Iterative, is flexible,
experimental, and likes to test small parts, learn from mistakes, and improve gradually.
Both want to help you build the house, but their styles are very different. This, in
essence, is the difference between the Waterfall Model and the Iterative Model in
software development. Let’s dive deeper into their stories.
The Waterfall Model: A Straight Path
1. What is the Waterfall Model?
Easy2Siksha Sample Paper
The Waterfall Model is one of the earliest models of software development. Imagine a
waterfall on a mountain. The water starts at the top and flows downward in a straight
line—once the water flows past one level, it cannot go back up. Similarly, in the
Waterfall Model, software development follows a linear sequence. Each step must be
completed before moving on to the next.
It’s like saying: “First plan everything, then design everything, then code everything, then
test everything, and finally deliver everything.”
2. The Stages of the Waterfall Model
The model is divided into distinct phases, like stepping stones:
1. Requirement Analysis – Talk to the client, gather all requirements, and
document everything.
2. System Design – Create the blueprint of the software, plan architecture, and
decide how the system will work.
3. Implementation (Coding) – Developers write the actual code according to the
design.
4. Testing – The software is tested for bugs, errors, and whether it meets the
requirements.
5. Deployment – Deliver the final product to the customer.
6. Maintenance – Fix issues, provide updates, and keep the software running
smoothly.
3. A Simple Example of Waterfall
Let’s return to the dream house analogy.
• First, you and Mr. Waterfall carefully write down every detail: number of rooms,
type of paint, design of windows, etc.
• Then, you make a full blueprint of the house.
• Next, you call the builders to construct it exactly as per the plan.
• After construction, you carefully inspect the house.
• Finally, you hand over the house to the family who will live there.
Notice something? If midway through construction, the family says, “Actually, we want
an extra balcony,” it’s almost impossible. Because in the Waterfall style, requirements
are fixed from the beginning.
Easy2Siksha Sample Paper
4. Strengths of the Waterfall Model
• Very structured and organized.
• Easy to manage because every phase has a clear beginning and end.
• Works well for small projects where requirements are very clear.
• Easy to explain to clients, since it follows a simple linear flow.
5. Weaknesses of the Waterfall Model
• Very inflexible—once you pass a stage, going back is difficult.
• If requirements change (which they often do), the whole project may suffer.
• Testing happens at the end, so errors discovered late can be very costly.
• Not suitable for large or complex projects where things evolve over time.
The Iterative Model: Step-by-Step Evolution
1. What is the Iterative Model?
Now let’s meet Mr. Iterative. He believes that perfection cannot be achieved in one go.
Instead, he suggests: “Let’s build a small version first, show it to the client, take
feedback, improve it, and repeat this process until the final product is ready.”
This is the Iterative Model. It develops software in small cycles (iterations). Each cycle
results in a working version of the software, which gets better and better over time.
Easy2Siksha Sample Paper
2. The Stages of the Iterative Model
Each iteration typically goes through these steps:
1. Planning & Requirement – Identify a small part of the requirements.
2. Design – Create a design for that part.
3. Implementation (Coding) – Write code for it.
4. Testing – Test the partial system.
5. Review & Feedback – Share it with the client, gather feedback.
6. Refinement – Improve it and start the next cycle.
The process continues until the full system is developed.
3. A Simple Example of Iterative Model
Let’s again use the dream house analogy.
• Mr. Iterative says: “Instead of building the whole house at once, let’s first build a
small prototype room and show it to the family.”
• The family says: “Nice, but we want more sunlight in this room.”
• Next iteration: you add bigger windows.
• Then you build the living room and show it again. The family suggests some
changes.
• Step by step, the house gets completed, and by the end, it is much closer to what
the family really wanted.
This model allows flexibility and handles changes well.
4. Strengths of the Iterative Model
• Very flexible—changes can be made at any stage.
• Errors are caught early since testing happens in every cycle.
• The client sees progress regularly, so they feel involved.
• Best suited for large projects where requirements may evolve.
• Risk management is easier because problems are solved in smaller parts.
5. Weaknesses of the Iterative Model
Easy2Siksha Sample Paper
• Requires more resources and planning.
• Can become time-consuming if too many iterations are needed.
• Sometimes clients keep changing requirements endlessly (“scope creep”).
• Documentation may not be as detailed as in Waterfall.
6. Diagram of the Iterative Model
Iteration 1 → Iteration 2 → Iteration 3 → ... → Final Product
(Each iteration = Planning → Design → Implementation → Testing → Feedback)
(Think of it as a spiral or cycle repeating until the product is complete.)
Waterfall vs Iterative: Head-to-Head Comparison
Let’s now put our two friends side by side and see how they compare:
Feature
Waterfall Model
Iterative Model
Approach
Linear, step-by-step
Cyclical, repetitive
Flexibility
Inflexible (changes difficult)
Flexible (changes easy)
Requirements
Must be clear from the
beginning
Can evolve over time
Testing
Happens at the end
Happens in every iteration
Risk
Management
Risk discovered late
Risk handled early
Client
Involvement
Low (client sees product at
the end)
High (client sees progress
regularly)
Best For
Small projects with fixed
requirements
Large, evolving, or experimental
projects
Cost of Errors
Very high (discovered late)
Lower (discovered early)
Delivery
Final product delivered once
Partial working product delivered
frequently
Real-Life Example: Building Software
• Waterfall Example: Suppose a company is building software for railway ticket
booking. The requirements are fixed by the government, and they won’t change
much. Here, Waterfall works because everything is clear.
Easy2Siksha Sample Paper
• Iterative Example: Suppose a startup is creating a new social media app. The idea
is experimental, and users may demand new features (like stories, reels, likes,
etc.). Here, Iterative works better because the product evolves gradually with
user feedback.
Diagrams
Final Thoughts
The Waterfall Model is like a school teacher who wants all homework neatly done in
sequence before moving to the next lesson. It is strict, disciplined, and works well if
everything is known in advance.
The Iterative Model is like a friendly mentor who lets you try, fail, learn, and improve
step by step. It is flexible, adaptive, and ideal when things are uncertain.
Both models have their own charm. Choosing between them depends on the nature of
the project. If requirements are crystal clear and unlikely to change, Waterfall is perfect.
But if requirements are uncertain and need refinement through feedback, Iterative is
the winner.
Easy2Siksha Sample Paper
Q2. Dene the terms Metric and Measurement in Soware Engineering. Also explain
Funcon Point Calculaon with an example.
Ans: A Different Start: Imagine You Are Building a House
Before diving into software terms, let’s start with something familiar.
Suppose you are building your dream house. What do you need?
• A measurement tape to know how long and wide the walls should be.
• A scale to check the thickness of a pillar.
• A cost estimation of how much cement, bricks, and paint will be required.
Without measuring, how will you ever know if the house will be stable, spacious, and
affordable?
Now, think of software as a house but made of logic, code, and user requirements.
• Just like a civil engineer uses measurements and metrics for a physical house, a
software engineer uses measurements and metrics for software systems.
• And when the software is being built, we can’t just measure with a ruler. Instead,
we use things like Function Points to understand the "size" of software.
This is where Metric, Measurement, and Function Point Calculation come into play.
Step 1: Understanding Measurement in Software Engineering
Let’s first make the idea of measurement crystal clear.
Definition of Measurement:
In software engineering, measurement means assigning a number or value to a software
attribute so that we can understand and analyze it.
It’s like asking:
• How many lines of code are written?
• How much time did it take to test the module?
• How many errors were found during testing?
So, measurement = finding a value for something in software.
Example:
Easy2Siksha Sample Paper
• Suppose you wrote a program with 2000 lines of code. "2000" is the
measurement.
• If a testing phase took 15 days, "15 days" is the measurement.
In short, measurement is the raw data.
Step 2: Understanding Metric in Software Engineering
Now let’s step into metric.
Definition of Metric:
A metric is a standard way to interpret and evaluate the measurement. It is like a
yardstick to tell us how good, bad, efficient, or complex the software is.
So while measurement is about numbers, metric is about meaning.
Example:
• If you say your program has 2000 lines of code (measurement), the metric could
be "average lines of code per module."
• If you tested for 15 days (measurement), the metric could be "defects found per
day."
So, metrics = meaningful interpretation of measurements.
House Analogy Continued
Think back to the house example:
• When you measure the wall as "10 feet," that is a measurement.
• When you compare it with standard rules (like “every room wall should be at
least 12 feet”), that is a metric.
That’s exactly what software engineers do:
• Measurement tells the raw data.
• Metric tells us whether that data indicates good, bad, or average software
quality.
Step 3: Why Do We Need Metrics and Measurements?
Easy2Siksha Sample Paper
Now, why do software engineers even care about these?
Because software is invisible! Unlike a building, you cannot see the "size" of software by
looking at it. You need a scientific way to:
• Estimate the effort (how many people will work).
• Estimate the cost (how much money will be spent).
• Estimate the time (how long it will take).
• Measure quality (is it reliable, maintainable, efficient?).
So, metrics and measurements bring objectivity into software engineering.
Step 4: Enter Function Point Analysis (The Hero of This Story)
Now let’s get into the core part of the question: Function Point Calculation.
Suppose your friend asks you:
"Hey, you are building software. How big is it?"
You can’t say: "It’s 500 MB in size." That doesn’t explain the actual complexity.
You can’t say: "It took me 20,000 lines of code." That’s not user-friendly.
Instead, you want a way to explain the size of software based on what it does for the
user.
This is where Function Points (FPs) come in.
What Are Function Points?
A Function Point is like a unit of measurement for software functionality.
• It doesn’t count lines of code.
• It doesn’t depend on the programming language.
• It simply measures how much functionality the user gets.
In short: Function Points measure the size of software in terms of what it delivers to
the user.
Step 5: Components of Function Point Calculation
Easy2Siksha Sample Paper
To calculate function points, we break the software into five basic components:
1. External Inputs (EI):
o Data that comes into the system.
o Example: Login form where the user enters username and password.
2. External Outputs (EO):
o Data that comes out of the system.
o Example: A report generated by the system.
3. External Inquiries (EQ):
o Interactive inputs and outputs (queries).
o Example: Searching for student details in a college database.
4. Internal Logical Files (ILF):
o Files maintained inside the system.
o Example: Customer database of a bank.
5. External Interface Files (EIF):
o Files used from outside the system.
o Example: Importing tax tables from government software.
Each of these elements has weights (low, average, high), depending on complexity.
Step 6: Function Point Calculation Formula
The process involves:
1. Count the number of each component (EI, EO, EQ, ILF, EIF).
2. Assign weights (low, average, high) to each.
3. Calculate Unadjusted Function Points (UFP):
4. Apply Complexity Adjustment Factor (CAF):
There are 14 general system characteristics (like performance, usability, data
communication). Each has a rating from 0 to 5.
5. Final Function Points (FP):
Easy2Siksha Sample Paper
Step 7: Example of Function Point Calculation
Let’s take an example: A small Library Management System.
Step 1: Count Components
• External Inputs (EI): Add book, add student, issue book, return book → 4
• External Outputs (EO): Print book report, print issue report → 2
• External Inquiries (EQ): Search book, search student → 2
• Internal Logical Files (ILF): Book file, Student file, Issue file → 3
• External Interface Files (EIF): External student database → 1
Step 2: Assign Average Weights
(Let’s assume average complexity for all)
• EI = 4 × 4 = 16
• EO = 2 × 5 = 10
• EQ = 2 × 4 = 8
• ILF = 3 × 7 = 21
• EIF = 1 × 5 = 5
Step 3: UFP
UFP=16+10+8+21+5=60
Step 4: CAF
Suppose after evaluating 14 factors, total complexity value = 30.
Step 5: Final FP
So, the size of this library management software is 57 Function Points.
Step 8: Diagram for Clarity
Here’s a simple diagram to visualize Function Point components:
Easy2Siksha Sample Paper
Step 9: Importance of Function Point Analysis
Why is this important?
• It’s language-independent (works whether you use Java, Python, or C++).
• It helps in cost estimation (how much effort needed).
• It’s user-focused (measures what the user gets, not what programmer writes).
• It improves project planning and quality control.
Step 10: Wrapping It Up Like a Story
So, if we connect the whole journey:
• Measurement is like noting the height of your wall.
• Metric is like saying whether that height is sufficient or not.
• And Function Points are like calculating the overall size of your house, not by
bricks, but by the rooms, windows, and doors that serve people.
In software, function points measure size based on what services the user receives, not
how many lines of code you write.
“This is only a part of the preparation journey.
For full access to repeated questions and detailed answers, purchase our
Premium Papers and boost your chances of scoring higher!”
